Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(marker_radar_lidar_calibrator): marker_radar_lidar_calibrator support for different radar msgs and transformation algorithms #180

Open
wants to merge 440 commits into
base: tier4/universe
Choose a base branch
from

Conversation

vividf
Copy link
Contributor

@vividf vividf commented Jul 23, 2024

Description

Same description as #161 after rebasing on the documentation branch.

Our previous tools assumed that radar has no elevation and we provided two algorithms:

  • Yaw-only calibration
  • x,y, yaw calibration

With elevation, we can get the full 6D pose. However, some sensors may impose restrictions on the orientation. In particular, the ARS548 imposes roll=0 for its object interface. We need an algorithm that easily accommodates this new restriction.

With this PR, we provide four algorithms

  • Yaw-only calibration (yaw_only_rotation_2d)
  • x,y, yaw calibration (svd_2d)
  • 3d calibration (svd_3d)
  • 3d transformation with roll is restricted to zero (roll_zero_3d)

and three different input msg-type for radar

  • radar_tracks
  • radar_scan
  • radar_cloud

Additionally, this PR also includes the xx1 gen2 project in the sensor_calibration_manager.

Related links

Tests performed

Notes for reviewers

Pre-review checklist for the PR author

The PR author must check the checkboxes below when creating the PR.

In-review checklist for the PR reviewers

The PR reviewers must check the checkboxes below before approval.

  • The PR follows the pull request guidelines.
  • The PR has been properly tested.
  • The PR has been reviewed by the code owners.

Post-review checklist for the PR author

The PR author must check the checkboxes below before merging.

  • There are no open discussions or they are tracked via tickets.
  • The PR is ready for merge.

After all checkboxes are checked, anyone who has write access can merge the PR.

vividf and others added 30 commits May 29, 2024 11:17
Signed-off-by: vividf <[email protected]>
Signed-off-by: vividf <[email protected]>
Signed-off-by: vividf <[email protected]>
Signed-off-by: vividf <[email protected]>
Signed-off-by: vividf <[email protected]>
Signed-off-by: vividf <[email protected]>
Signed-off-by: vividf <[email protected]>
Signed-off-by: vividf <[email protected]>
Signed-off-by: vividf <[email protected]>
Signed-off-by: vividf <[email protected]>
Signed-off-by: vividf <[email protected]>
Signed-off-by: vividf <[email protected]>
Signed-off-by: vividf <[email protected]>
Signed-off-by: vividf <[email protected]>
note: this was note made as another PR since it also involved documentation

Signed-off-by: Kenzo Lobos-Tsunekawa <[email protected]>
Signed-off-by: Kenzo Lobos-Tsunekawa <[email protected]>
Signed-off-by: Kenzo Lobos-Tsunekawa <[email protected]>
Signed-off-by: Kenzo Lobos-Tsunekawa <[email protected]>
Signed-off-by: vividf <[email protected]>
Signed-off-by: vividf <[email protected]>
} else if constexpr (std::is_same<RadarMsgType, radar_msgs::msg::RadarScan>::value) {
radar_pointcloud_ptr->reserve(msg->returns.size());
for (const auto & radar_return : msg->returns) {
float range = radar_return.range;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

kind of nit:
you are creating copies. whenever applicable use const references


void ExtrinsicReflectorBasedCalibrator::calculateCalibrationError(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

calculateCalibrationError and computeCalibrationError exist in this file with similar yet different purposes and signatures. This makes it very difficult to read. Choose one and overload, or use different more appropriate words

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current calculateCalibrationError is unnecessarily deep in the call hierarchy.
In code metrics, the less deep the better.

Semantically speaking it should be between:

estimateTransformation();
<-- 
crossValEvaluation();

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! fixed in c1a1ea3

"The pure rotation calibration pose was chosen as the output calibration pose. This may mean "
"you need to collect more points");
calibrated_radar_to_lidar_eigen_ = calibrated_rotation_radar_to_lidar_transformation;
this->get_logger(), "The calibration pose was chosen as the output calibration pose");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The output messages in this method make sense in the context of the code before this PR. Now they do not make much sense. Please fix them

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed in 9bee4d2


void ExtrinsicReflectorBasedCalibrator::crossValEvaluation()
{
int tracks_size = static_cast<int>(converged_tracks_.size());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you change the parts that correspond to std::size?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(this applies in several parts of the crossvalidation strategy )

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed them in b9e8c9d

@knzo25
Copy link
Collaborator

knzo25 commented Sep 30, 2024

@vividf
Everywhere in the code that a .z() = 0 exists, it is only applicable to the old 2D versions of the algorithm. This one is an important error, and any result that comes with it has a non negligible error
I was worried that the error that I saw using this tool was too high. Hopefully this one fixes it...

{
RCLCPP_INFO(
rclcpp::get_logger("marker_radar_lidar_calibrator"),
"Estimate 3D transformation with roll is always zero");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a statement ?!?!?!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed the logging to 12b3562

RCLCPP_INFO(
rclcpp::get_logger("marker_radar_lidar_calibrator"), "%s", initial_params_msg.c_str());

for (size_t i = 0; i < lidar_points_ocs_->points.size(); i++) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have been trying to use std::size_t so far

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

addressed in 28fdcf9


ceres::CostFunction * cost_function = new ceres::AutoDiffCostFunction<SensorResidual, 3, 5>(
new SensorResidual(radar_point_eigen, lidar_point_eigen));
problem.AddResidualBlock(cost_function, NULL, params.data());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nullptr

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, fixed in ef70435

Copy link
Collaborator

@knzo25 knzo25 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left several comments. The algorithm is solid, but this PR still needs quite a lot of work.
When I have a commit more stable to do some evaluations I will probably have more comments, but I will wait until the current comments have been addressed

@vividf vividf requested a review from knzo25 October 7, 2024 07:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants